1. Field of the Invention
Embodiments of the present invention relate generally to the field of computer networking and more specifically to a single logical network interface for advanced load balancing and fail-over functionality.
2. Description of the Related Art
A network computing device oftentimes has two or more network interface cards to increase the computing device's communication bandwidth beyond what a single NIC is able to provide. Such a plurality of NICs is commonly referred to as a “team” of NICs. Typically, the team shares a common Internet Protocol (IP) address while maintaining unique Media Access Control (MAC) addresses for each NIC within the team. One aspect of using this team configuration is that network traffic between the computing device and other computing devices in the network may be distributed among the NICs in the team such that the overall throughput of the team may be maximized. This type of operation is referred to as “load balancing.” Another aspect of using a team configuration is that network traffic may be migrated from a nonfunctional or unreliable NIC within the team to a functional or more reliable NIC within the team. This type of operation is referred to as “fail-over.” The combination of load balancing and fail-over in a single implementation is typically referred to as “LBFO.”
For an LBFO implementation to set up and migrate network connections between NICs to optimize the computing device's network communications throughput and reliability, the LBFO implementation may monitor operational parameters at the NIC level, such as the error rate on each NIC and the amount of data exchanged through each network connection. Typical LBFO implementations locate their LBFO software in the operating system and request the NIC-level operational parameters from the NIC hardware through one or more device drivers. The resulting architectures are inherently inefficient because they place the LBFO decision making and management functionalities several software levels away from where the operational parameters are monitored, requiring a substantial amount of ongoing communication between software levels. Further, to decrease the communication required between software levels and/or because the LBFO implementations in operating systems are not fully optimized for LBFO, the LBFO decision making elements in prior art LBFO implementations may not utilize all operational parameters available at the NIC level. Thus, LBFO implementations residing in operating systems may be lower performing due to excessive software communications between software levels and LBFO decision making based on limited NIC-level operational information.
In addition, for an LBFO implementation to be reliable and to maintain high performance, its configuration should not be subject to change by either the operating system or some third party, such as a user or an application program. Typical LBFO implementations expose each NIC in the team to the operating system, giving the operating system a substantial degree of control over the NICs, including the ability to reconfigure any of the NICs. In such implementations, the operating system may be able to change the IP address associated with the team of NICs or change the security settings or communications parameters for a particular NIC. Further, to the extent the NICs are also exposed to third parties as a result of their exposure to the operating system, a third party may be able to similarly reconfigure the NICs. For example, a user may be able to mistakenly disable or reconfigure a reliable NIC or mistakenly enable an unreliable NIC. As a general matter, a team of NICs is configured to optimize a particular LBFO architecture. Unilaterally reconfiguring a NIC once that NIC has been configured for a team may very well undermine that optimization, thereby lowering the performance and/or reliability of the computing device's network communications.
Further, for a LBFO implementation to be most useful in modern networks, the implementation should account for additional security features that may be in use in the network. One such security feature is the Institute of Electrical and Electronics Engineers (IEEE) security credentials protocol (hereafter referred to as “802.1X”), which improves network security by requiring a NIC to request authentication from a security credential server before the NIC may communicate with a switch. Another security feature is the IEEE “Virtual LAN” protocol (hereafter referred to as “802.1Q”), which may also improve network security by allowing a network administrator to configure a range of IP addresses as a virtual LAN (VLAN) and selectively assign machines to the VLAN, thereby enabling communications between machines in the VLAN and preventing communications between machines inside the VLAN and those outside the VLAN. Each of these protocols imposes additional constraints on the LBFO implementation. Consequently, one drawback of existing LBFO implementations is that they do not always implement LBFO within the constraints of the aforementioned security (802.1X and 802.1Q) protocols.
As the foregoing illustrates, what is needed in the art is an LBFO architecture that addresses one or more of the drawbacks of existing LBFO implementations set forth above.